fix(logs): Split flex time page params from existing page params #101176
Conversation
github-actions
bot
added
the
Scope: Frontend
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| }; | ||
|
|
||
| return pageParamResult; | ||
| } |
There was a problem hiding this comment.
Bug: Flexible Pagination Overlaps With Cursor-Based
The getNextPageParam function's condition for flex time pagination (highFidelity || isFlexTimePageParam(pageParam)) is too broad. It now uses cursor-based pagination if highFidelity is true or if the previous page was flex time, even if isDescending or autoRefresh conditions don't warrant it. This can cause inconsistent pagination behavior.
![seer-by-sentry[bot]](https://avatars.githubusercontent.com/in/801464?s=60&v=4){kind=small}
| const link = isGetPreviousPage ? links.previous : links.next; | ||
| if (!link?.results) { | ||
| return undefined; | ||
| } |
There was a problem hiding this comment.
Potential bug: Backward pagination is broken in 'flex time' mode due to incorrect handling of forward-only logic.
-
Description: In 'flex time' mode, which is strictly forward-only, the code attempts to handle previous page requests. This causes the pagination logic to return
undefinedbecause the API correctly reports no previous page is available, leading to broken backward pagination functionality. -
Suggested fix: The code should explicitly handle the case where a previous page is requested in 'flex time' mode, either by preventing the request or by providing a clear state to the UI, instead of returning
undefinedand causing a silent failure.
severity: 3.0, confidence: 5.0
Did we get this right? 👍 / 👎 to inform future reviews.
Mixing the 2 into 1 type is confusing and this is in preparation to auto fetch the next page if the current page is empty which is possible with the flex time strategy.